System management method and apparatus

ABSTRACT

To facilitate the carrying out of a range of different types of management task in a computer system (such as fault diagnosis and service installation), declarative models (22) are constructed of the various services provided by the system (10-13). These models (22) specify the requirements that need to be met for the corresponding service to be available. These requirements are set out in terms of the system entities that need to be present and the inter-relationships of these entities. In addition, each management task is specified in a corresponding task program (21) in terms of general inferencing operations that can be performed on any of the models. Execution of a particular management task involves carrying out inferencing operations on the appropriate service model (22) in accordance with the task program (21) for the management task under consideration.

FIELD OF THE INVENTION

The present invention relates to a system management method andapparatus for carrying out at least one management task in relation toat least one service intended to be provided by a computer system. Inparticular, but not exclusively, the present invention relates to amethod and apparatus for facilitating the carrying out of a number ofmanagement tasks (such as installation, monitoring, and fault diagnosis)in relation to a number of different services (such as log-on,electronic mail, and print spooling) provided on a network of computers.

BACKGROUND ART

Over recent years the complexity of computer systems (and in particular,computer networks) has increased considerably, such systems beingcharacterised by the interaction of multiple system entities inproviding a variety of different services. One result of this is to haveplaced a considerable strain on system management resources tasked tokeep such systems up and running. Whilst low-level fault-diagnosisequipment such as protocol analyzers have evolved generally in line withthe increasing sophistication of the technologies used for inter-linkingsystem entities, such equipment has often tended only to serve as an aidto a maintenance engineer, telling him/her what is wrong at theparticular point under test. Similarly, higher-level network managementsystems that seek to provide an overview of overall system performanceby collecting data from all parts of a network, have largely been oflimited use leaving much of the problem of understanding what is goingon to the network supervisor.

More recently, a number of proposals have been made to introduce expertsystem technology to network fault diagnosis and management. One networkmanagement system using such technology is the ANM (Automated NetworkManagement) system described in the article "ANM: Automated NetworkManagement System" by Feridun, M Leib, M Nodine and J Ong, IEEE Network,March 1988--Vol 2, No 2. In the ANM system, network entities such asgateways, provide data to a backbone of Distributed Management Modules(DMMs) which service `Clients` that provide the network managementservices. Clients request and receive raw data collected from networkentities by the DMM backbone; Clients can also request the DMM backboneto execute specific actions. A specialised Client called an IntelligentNetwork Manager is provided and comprises a collection of expert systems(Experts) organised as a top-level Expert which forwards triggering datareceived from the network entities to other Experts that each understanda specific kind of network problem. These Experts, in turn, may suggestpossible hypotheses that might explain the triggering data. Ifnecessary, each Expert may request additional data from networkentities. When Experts suggest, confirm or reject hypotheses, thenetwork operator is informed. To add expertise about a new type ofnetwork problem, to the Intelligent Network Manager of ANM, a new Expertmust be added to the system, and to change the way the system reasonsabout problems, all Experts conducting such reasoning must be changed.

Another example of the use of expert system technology in the field isthe network monitoring and analysis apparatus described in EuropeanPatent Application 0 473 255 A2 (Hewlett-Packard). This apparatus isalso provided with a number of different expert systems (Consultants);however, unlike the ANM system in which the Experts are concerned withrespective types of network problem, in the Hewlett-Pochard apparatuseach Consultant is concerned with a respective one of the types ofoperations normally involved in the analysis of any given networkproblem.

In both these latter arrangements, expert knowledge is encoded in expertsystems with the object of identifying network faults given a set ofsymptoms and suggesting possible solutions. Any knowledge about whatshould be happening on the system is closely bound to the problem to besolved. As a result, the expert knowledge is not available for use inother types of management task where no fault exists, such asinstallation of a service. This trait is characteristic of today'ssystems that seek to provide assistance in the carrying out of networkmanagement tasks and one consequence of this has been that eachmanagement task tends to have its own special aids (generally in theform of software tools) the number of which for each task corresponds tothe number of network services in respect of which the task is to beeffected.

It is an object of the present invention to facilitate system managementby providing expert knowledge about the system in a more useful form.

DISCLOSURE OF THE INVENTION

In general terms, the present invention achieves this object byspecifying the requirements needed for a particular service to beavailable in the form of a declarative model and then definingmanagement tasks in terms of general inferencing operations that can becarried out on such models. As a consequence, each service model can beused by each task.

As used herein, the term "declarative model" refers to an abstractdescription of a service, the meaning of the model being independent ofany form of processing to which the model may be subject; a model thushas no notion of sequence, iteration or choice in relation to how it isto be used (in contrast to what is typically the case with imperativemodels) and, instead, the model employs logical operators (such as AND,OR ,NOT) and recursion as appropriate. Of course, concepts of sequence,iteration and choice may well be represented in the model as part of themodelling of the service concerned but this does not affect thedeclarative nature of the model.

It should be noted that the type of model here referred to isfundamentally different from that disclosed in International ApplicationWO 92/05485 (Cabletron Systems) where a `virtual network` simulating areal network being managed, is built up from `models` of each entity inthe real network. Neither the `virtual network` nor the individual`models` of the Cabletron system seek to describe a network services asis the case in the present invention; furthermore, the Cabletron`models` have a one-to-one correspondence with real world items whichagain differs from the present invention where a single service modeldefines the requirements of a service regardless of whether there arenone, one or many actual instances of the service in the real system.

More formally stated, according to one aspect of the present invention,there is provided a system management method for carrying out at leastone management task in relation to at least one service intended to beprovided by a computer system made up of cooperating physical andlogical entities, the method comprising the steps of:

providing for the or each said at least one service, a respectivedeclarative model specifying independently of any particular said task,the requirements needing to be met for the service to be available,these requirements being set out in terms of the entities required andtheir inter-relationships,

providing for the or each said at least one management task, respectivetask control means for controlling performance of the corresponding taskin a manner independent of any particular said model and in terms ofgeneral inferencing operations that can be performed on any said model,and

performing a said at least one management task in relation to a said atleast one service by a process involving effecting inferencingoperations on the corresponding declarative model under the control ofthe said task control means relevant to that management task.

Preferably, each said task control means comprises a respective taskprogram for controlling the operation of an inference engine to performthe corresponding task, the same engine being used for each taskregardless of the model to be processed. However, it is also possible toarrange for a said task control means to be embodied in the functionalarchitecture of an inference engine thereby specifically adapting thatengine for the corresponding task; in this case, there will be arespective inference engine for each task to be performed. Anintermediate approach is also possible where the functional architectureof a common inference engine is determined by the task to be performedbut, in addition, there is a task program exercising this functionalityin a programmed manner; this approach is feasible due to the fact thatinference engines are generally implemented by software routines onstandard hardware so that the functionality of the inference engine canbe changed by altering the inter-relationship of its component routines.

The system management method of the invention is particularlyadvantageous where there are multiple services and multiple tasks to beperformed as it avoids the need to write special programs to carry outeach pairing of service and task. However, the method is also applicablewhere there is only one service provided or only one task to beperformed.

Generally, the computer system to be managed (typically a computernetwork) will be capable of supporting a plurality of instantiations ofa service, the step of carrying out a management task in relation tothat service involving identifying an instantiation of the service andthen using the appropriate service model to inference information inrelation to the identified service instantiation.

Advantageously, the declarative model of a service comprises ahierarchical structure of declarative statements inter-relatingentities, statements lower in the hierarchy serving to detailrequirements specified by statements higher in said hierarchy.

These statements may include, in addition to statements directlyspecifying requirements, statements generally inter-relating entitiesand usable to infer whether a particular requirement has been met. Whereappropriate, a model can be associated with another such that statementsset out in one model and involving a particular entity, are usable inthe other model in connection with the same entity.

The requirements specified in a service model can advantageously bedivided into sets, namely a set of essential technical requirements anda further set of operating policy requirements setting out, for example,names to be used for particular files.

Advantageously, to facilitate the carrying out of a management task,information on the system is made available through reference to a factbase which can be updated through interaction with the system to providedesired information (in this latter case, the desired information isascertained either directly through queries designed to elicit specificitems of information, or indirectly by inferencing from the results of aparticular system function exercised by the interaction).

The system management method is applicable not only to tasks where thecomputer system is left unaltered by the task (for example, a faultdiagnosis task), but also to tasks (such as installation of a servicefor a particular user) that require the system to be changed in somemanner (by adding or removing an entity or by modifying theinter-relationship between at least two entities).

According to another aspect of the present invention, there is providedsystem management apparatus for carrying out at least one managementtask in relation to at least one service intended to be provided by acomputer system made up of cooperating physical and logical entities,the apparatus comprising:

for the or each said at least one service, a declarative modelspecifying independently of any particular task, the requirementsneeding to be met for the service to be available, these requirementsbeing set out in terms of the entities required and theirinter-relationships,

inference engine means for carrying out inferencing operations inrelation to a said declarative model,

for the or each said at least one management task, respective taskcontrol means for controlling performance of the corresponding task bysaid inference engine means in a manner independent of any particularservice model and in terms of general inferencing operations, and

means for causing a management task to be carried out in relation to aparticular service by causing said inference engine means to operate onthe corresponding declarative model under the control of the taskcontrol means relevant to that management task.

Preferably, the system management apparatus further comprises fact basemeans for storing facts about the system, and interaction means forinteracting with the system to ascertain either directly or throughinferencing from the results of the interaction, facts about the system,the inference engine means being operative in the course of carrying outa said management task to check whether a said requirement is being metby the system by referring to the fact base means and in the event thatinsufficient facts are present in the fact base means, by causing theinteraction means to interact with the system to elicit further facts.

BRIEF DESCRIPTION OF THE DRAWINGS

System management apparatus embodying the present invention will now bedescribed, by way of non-limiting example with reference to theaccompanying diagrammatic drawings, in which:

FIG. 1 is a depiction of a computer system as seen from the perspectiveof an end user;

FIG. 2 is a depiction of a computer system as seen from the perspectiveof a system manager;

FIG. 3 is an overview diagram of the system management apparatusembodying the invention showing the any-to-any pairing of task programsand service models;

FIG. 4 is a diagram of an inference engine of the FIG. 3 apparatus;

FIG. 5 is a search tree illustrating operation of the FIG. 4 inferenceengine in respect of an example service model, when given a set ofpredetermined facts;

FIG. 6 is a search tree illustrating operation of the FIG. 4 inferenceengine in respect of the same service model as for FIG. 5, but wherequeries are used to elicit facts;

FIG. 7 is a diagram illustrating the format of a service model includingthe definition of three entity types with associated relations;

FIG. 8 is a diagram illustrating inheritance between service-modelentities and importation across models;

FIG. 9 is a diagram of the functions involved in providing a printspooler service to a network user;

FIG. 10 is a drawing of how the FIG. 9 service can be expressed in termsof service models and entities;

FIG. 11 is a diagram illustrating the format of a query usable to obtaininformation from the computer system being managed; and

FIG. 12 is a drawing of syntactic parsing of a return string givinginformation about a user of the computer system being managed.

BEST MODE FOR CARRYING OUT THE INVENTION OVERVIEW

FIG. 1 is an illustration of a computer system comprising work stations10 and peripheral devices 11 (for example, printers) inter-connected viaa network including LAN segments 12 linked via bridges 13. FIG. 1 is adepiction of an end-user's view of the system. An end-user 14 working ata work station 10 wants the system to provide her/him with one or moreservices 15 such as logging into the computer system, running aparticular application program, print spooling, electronic mail, and logoff.

FIG. 2 is a depiction of for the same computer system as FIG. 1 a theview of the system taken by a system manager 16 also working at a workstation 10 of the system. For each service available to an end user onthe system, the system manager 16 must be ready to carry out a number oftasks 17 including installation of the service, configuration of theservice, fault diagnosis, fault fixing and removal of the service. Tothis end, the system manager's work station runs appropriate softwarethat turns the work station into a management system for carrying outeach task in relation to each service. In prior art systems, thismanagement system has required the writing of specific programs for eachpairing of service and task. The management system to be describedhereinafter and which embodies the present invention obviates this needand requires only the characterisation of each task and of each serviceseparately.

The general form of the system management apparatus embodied in thepresent invention is shown in FIG. 3. The main components of theapparatus are a set of task programs 21 (one for each of the m tasks tobe performed), a set of service models 22 (one for each of n servicesprovided by the computer system), and a management system 20 constitutedby work station 10 of the computer system and appropriate software.

Each service model 22 is a declarative model of the service concernedand specifies the requirements needing to be met for the service to beavailable. These requirements are set out in terms of relationshipsbetween the physical and logical entities of the computer system. Aservice model contains no information about how it is to be used fordifferent management tasks. Associated with each service model arequeries and actions 28. Queries detail how information regarding therequirements specified for the service concerned may be obtained byinter-action with the computer system. Actions detail how to initiatethe carrying out of procedures relevant to the modelled service that maybe required to implement certain tasks.

The management system 20 comprises an inference engine 25, a fact base26 and an inter-action manager 27. When carrying out any particular taskunder the control of one of the task programs 21, the inference engine25 uses the service model for the service in respect of which the taskis being carried out, to identify the requirements for the service andthen uses whatever information might be available to it, to make certaininferences from these requirements (in particular, whether they havebeen met or need to be met). The fact base 26 stores facts already knownto the management system and which are therefore directly available tothe inferencing engine 25. If desired facts are not in the fact base 26,the inference engine 25 is operative to use the queries associated withthe relevant service model 22 to cause the inter-action manager 27 tointeract with the computer system with a view to obtaining the factsconcerned directly or indirectly through experience. Furthermore, if itis necessary to modify the system being managed in order to complete atask (for example, installation or removal of a service), the inferenceengine is operative to cause appropriate predefined actions associatedwith the relevant service model 22 to be initiated via the interactionsmanager 27.

By way of illustration and using a pseudo natural language, a loginservice model in respect of a user login service may specify that theservice is available to an intending user if four requirements are met:

Login service is ok for intending user called Name, IF:

the system has a record of a user by this Name, and

this user has a password, and

this user has a home directory, and

this user has execute access to that directory.

If now it is wished to carry out diagnosis of the login service for aparticular user, a diagnosis task program causes the inference engine 25to examine the login service model and identity all the requirementsthat must be met. For example, if a user called "John" cannot login,then the model states that the system must know about a user with thatname, that he must have a password, that he must have a home directory,that he must have execute access to that directory; the inference engine25 proceeds under the control of the diagnosis task program to ascertainwhich of these requirements has not been met.

Should it be desired to add a new user to the system, an "add-user" taskprogram causes the inference engine 25 to examine the login servicemodel to identify what requirements must be met for the new user to beable to login; these requirements can then be met by appropriate actionson the system.

The task programs, service models, queries and actions will allgenerally be written in a high-level language and compiled to objectcode for execution.

INFERENCE ENGINE

The general form of the inference engine 25 is illustrated in FIG. 4.Conceptually, the inference engine comprises a task control layer 30 forcontrolling the inference engine in accordance with the task program 21supplied to it; a proof system made up of a verifier 31, a knowledgeassimilator 32 and a theorem prover 33; and a logic support layer(providing for unification, predicates and variables) provided by anappropriate language such as Prolog or Smalltalk both of which are wellknown to persons skilled in the art.

With regard to the proof system, the verifier 31 uses a closed worlddeduction system for which if something cannot be proved true it isassumed to be false; the verifier does not utilise queries. The verifier31 is thus useful for discovering what can be true given the currentstate of knowledge. The knowledge assimilator 32 uses a form ofabduction in order to find consistent extensions to the fact base thatare sufficient to explain observations arising from the results ofqueries. The main theorem prover 33 is an open world deduction systemthat also considers queries; it is the core of the inference engine. Therole of the task control 30 is to integrate the operation of theelements of the proof system in a manner to produce the results desiredfor the task being effected; generally, however, it may be said that ifthe theorem prover 33 is unable to prove a particular theorem on thebasis of facts currently available in the fact base, it will ask theverifier 31 to look at the queries to find one which will provide itwith the facts desired, and then once its query has been performed, theknowledge assimilator will extract as much information as possible fromthe results of the query and store this new information in the fact basefor use by the theorem prover 33.

A simple example of how the theorem prover 33 carries out reasoning onthe basis of the rules given it in a service model 22 and having regardto facts available in the fact base 26, will now be given.

Each service model contains statements relating to the entity orentities relevant to that model and these statements will generally beused to form a number of rules (conditional relationships) specifying,for example, that a service entity is available if certain conditionsare met. Thus with reference to the service model 22 of FIG. 4, theremay be truth valued statements A-H in the service model organized intothree rules:

A if B or C

B if D and E and F

C if G or H

Statement A may represent that the service concerned is available ifstatement B or statement C is true. The second rule given above thensets out the conditions to be fulfilled for statement B to be truewhilst the third rule gives the conditions for statement C to be true.

By way of example, consider first the situation that the fact basecontains the facts that D, F and G are true but E and H are false.Working with the above rules and these facts, the main theorem prover 33can now deduce whether or not the service represented by model 22 isavailable--that is, whether A is true. This prove proceeds as follows(See FIG. 5):

(1) Since there is no fact for A but there is a rule, the search for asolution expands into two partial solution nodes.

(2) Now consider B. Again there is no fact, but there is a relevant ruleso the search is again expanded.

(3) Now consider D,E,F. There is a fact for D, so the next partialsolution is node E,F.

(4) Now consider E,F,E is known to be false, so this branch fails.

(5) Backtracking to the next un-expanded partial solution node (that is,C), there is no fact for C, but there is a rule, so the search isexpanded.

(6) Now consider G. This is known to be true, so a solution has beenfound.

Note, this example is just a simple depth-first search over the solutionspace. Other search strategies are, of course, also possible such as a"best first" strategy.

Consider next the situation where there are no facts in the fact base26. However, a set of queries is associated with the model 22 providingtwo queries Q1 and Q2; query Q1 is `goodfor` (that is, will give thevalue of) D and E and Q2 is `goodfor` F,G and H. In this case, the proofproceeds as follows (see FIG. 6):

(1) The proof of A begins as before until the partial solution nodeD,E,F is reached. This time there is no fact for D but there is a queryQ1. So, query Q1 is executed and this puts the facts `D is true` and `Fis false` into the fact base, enabling the next partial solution node tobe created.

(2) Now consider E,F. There is now a fact for E in the fact base; thisfact (E is false) causes this branch to fail.

(3) Backtracking to the next un-expanded partial solution node (that is,C) the search is continued as before.

(4) When G is considered, there is no fact for it, but there is a queryQ2. When this is executed the facts `F is true`, `G is true` and `H isfalse` are added to the fact base which results in a solution.

The selection of the appropriate query and the extraction of informationfrom the result of a query involve the verifier 31 and knowledgeassimilator 32.

Of course, the foregoing examples are very simple but serve toillustrate the general operation of the inference engine 25 in relationto the models 22, queries 23 and fact base 25.

SERVICE MODELS

A service model specifies a service provided by the system in terms ofsystem entities associated with the service and the relations betweenthese entities.

Entities are items about which facts can be asserted and may correspondto logical objects such as integers, files, operating modes, etc or toreal-world physical objects such as machines, printers etc. A number ofprimitive or core entity types are conveniently pre-defined such asintegers, characters and strings and are implicitly available for use inany service model. Higher level entity types are then defined in anappropriate service model with the characteristics of each such entitytype being specified in terms of relations between core entities and/orpreviously-defined higher-level entities. Each entity type and itsassociated characterising relations are herein generally referred to asan Entity-Relations group (or `ER group` for short).

Relations may be basic, unconditional, relations between entities orderived, conditional, relations that are only true if one or moreconditions are satisfied (these conditions being themselves specified interms of relations between entities). A relation identifies at least oneentity and names a particular relation predicate. Generally, theentities in a relation will be specified in terms of variables of aspecific entity type, the variables only being bound when the servicemodel is used by the inference engine; however, specific entityinstances may be directly written into a relation (such as a nameconstituting a particular string entity).

In defining a relation, it may be useful to specify whether or not aninstance of one entity in the relation can relate to more than oneinstance of another entity in the same relation, this characteristic ofthe relation being termed its "cardinality". For example, one directorycan contain many files but each file can be in only one directory and itmay be useful to specify this property in any relations associatingfiles and directories.

A straightforward model will, for example, comprise an entitycorresponding to the service itself and an associated derived relationto the effect that the service entity is `OK` (that is, functional)provided a set of conditions are met, these conditions being particularrelations between entities involved in providing the service. Therelations associated with these latter entities permit a determinationto be made as to whether the conditions have been met for the serviceentity to be `OK`.

FIG. 7 illustrates, by way of example, a simple service model 50 for anotional service for deleting a file. This example model is considerablysimplified over what might be expected in practice and is given purelyto assist in demonstrating the concepts involved in service models;furthermore, the cardinalities of the relations involved have beenomitted for simplicity. The convention used in this specification isthat entity types are given initial capitals whilst correspondingvariables start with lower case letters and have generally similar namesto their entity type; in fact, the type of a variable is declared at thefirst occurrence of the variable except where the variable type isreadily apparent. Within a relation, entities (whether represented by avariable or specified as particular instances) are enclosed in squarebrackets and where the value of an entity does not matter (only that ithas one) the underscore symbol `₋₋ ` is included in the brackets. Thelogical operators AND, OR and NOT are represented by "," ";" and "˜"respectively.

The FIG. 7 service model 50 comprises a header 51 identifying the modeland three ER groups 52, 53, 54 defining three entity types, namely:

Delete₋₋ file--representing the service itself;

User--representing users known to the system;

File--representing files on the system.

String and integer core entities are also used.

The service entity Delete₋₋ file is declared in definition 55 of ERgroup 52. Associated with the definition 55 are two relations, namely:

a derived relation 56 that sets out the conditions 57 to 59 needing tobe met if an instance of the service (represented by variable `delete₋₋file`) is to be OK for a given user (represented by variable `user`) inrespect of a given file (represented by variable `file`). The variables`user` and `file` are of type User and File respectively and arespecifically declared as such.

a basic relation 60 giving the charging rate for the service (herespecified by the string `FREE`).

It will be noted that the second relation 60 is not used in determiningthe functional status of the service but asserts a relation that may beuseful for other purposes.

The essence of relation 56 is that the file deletion service isavailable to a user represented by the variable `user` in respect of afile represented by the variable `file` if the user owns the file(condition 57), no-one else is using the file (condition 58) and thelegal status of the file is explicitly `non retention`. It will beappreciated that when the conditions are applied, the same values arebound to corresponding variables in the various conditions, these valuesbeing those already bound to the variables in the first line of thederived relation 56.

ER group 53 defines entity type User and has one basic relation 61specifying that each user (as represented by variable `user`) has a useridentity that takes the form of an integer.

ER group 54 defines entity type File and has three basic relations 62,64, 65 and one derived relation 63. Relations 62, 64, 65 respectivelyattribute to a file (represented by variable `file`), an integer foridentifying the file owner, an integer for specifying the current numberof users of the file other than its owner, and a string for specifyingthe legal retention status of the file. Relation 63 sets out the twoconditions 66,67 requiring to be met for a given file to be owned by agiven user, namely that the file owner id should correspond to theuser's user id. It should be noted that this correspondence is specifiedby use of an integer variable `uid` that will have a value bound to itwhen during application of relation 63, the inference engine in seekingto prove conjunction of the statements forming the conditions 66, 67finds a relevant fact giving the owner id of a file, and applies this tocondition 66; the value of `uid` is now bound and condition 67 can betested.

It will be appreciated that the variables specified in the relationsincluded in a service model will have values assigned to them eitherexplicitly on initiation of a task (for example, by the system manager)or by reference to the fact base, or by use of the query system.

In more sophisticated models, where a number of closely related servicesexist such as a set of services provided by the same system object (forexample, a file system manager), then rather than having a separateentity for each such service, it is convenient to define a generalservice entity conceptually spanning all the related services (thisentity could be thought of as equating to the relevant service providerobject of the system). This general service entity is then associatedwith each specific service through a corresponding relation (normally aderived relation setting out the conditions for the specific serviceconcerned to be available). Thus, with reference to the foregoingexample of a service for deleting a file, a general service entity type"File₋₋ service" may be defined to encompass all file-related services.The file deletion service then takes the form of a derived relation:

    ______________________________________                                         file.sub.-- service! delete.sub.-- file.sub.-- for  User user! on  File      file! isOk IF:                                                                  file! is.sub.-- owned.sub.-- by  user!,                                       etc                                                                         ______________________________________                                    

This can be interpreted as saying that the instance of the File₋₋service entity type represented by the variable "file₋₋ service", canprovide the file deletion service for the user represented by thevariable "user", in respect of the file represented by the variable"file", provided the conditions specified after "IF" are met.

Two repetition-reducing mechanisms are preferably provided to preventundue repetition of the definition of entity types and relations thatmay otherwise occur in modelling any substantial service. Thesemechanisms are:

INHERITANCE between entity types so that one entity can inherit therelations of another, and

IMPORTATION enabling one model to make reference to entities in anothermodel.

These mechanisms will be considered further below with reference to FIG.8.

FIG. 8 diagrammatically depicts four models 70 named M1, M2, M3, M4respectively. Model M1 is shown as including six ER groups 71respectively relating to entity types named E1 to E6. Model M2 is shownwith one ER group 71 for an entity type named E7; model M3 is shown intwo ER groups 71 for an entity type named EIP. The relationscharacterising each entity type are not explicitly depicted.

As already described with reference to FIG. 7 a relation in one ER groupof a model may refer to an entity of a type defined in the same model.The reference to an entity of a first type from within a relation of anER group associated with a second entity type is herein referred to as"RIR" reference (derived from "Reference In Relation"). FIG. 8illustrates an RIR reference from a relation of the ER group associatedwith entity type E1 to an entity of type E2, this reference beingdepicted by an arrow.

Entity types within the same model may also be related by an "ISA"reference that specifies as inheritance relationship between twoentities whereby the relations associated with one entity are inheritedby another. If an entity inherits relations associated with anotherentity, this is declared in the definition of the entity type of theformer, typically by an "ISA" statement. An ISA relation is illustratedin FIG. 8 between the entity types E4 and E3 of model M1. The inheritingentity is referred to as the "sub-entity" and the entity whose relationsare inherited, is called the "super-entity". Inheritance may occur overseveral levels, building up a hierarchy of inheritance.

In most practical systems, multiple service models will be defined andit becomes useful to be able to make RIR and ISA references that extendacross model boundaries thereby to avoid duplication of the definitionsof common entity types and relations. This crossing of model boundariesis enabled by the aforesaid IMPORT mechanism by which any model referredto by another is explicitly declared in the latter in a sectionimmediately following the model name. Thus if a relation in the ER group71 associated with entity type E5 of FIG. 8 wishes to make an RIRreference to an entity of type E7 already defined in model M2, it can doso provided the model M2 has been declared in an "import" section 72 ofmodel M1. Similarly, entity type E6 of model M1 can use an ISA referenceto inherit the relations associated with entity type E8 of model M3,provided model M3 has been declared in section 72 of model M1.

In the example of FIG. 8, entity type E8 of model M3 is not only thesuperentity of entity type E6 of model M1 but is also a sub-entity ofentity type E9 of model M3 and, in addition makes an RIR reference to anentity of type E10 of model M4. The latter reference does, of course,require model M4 to be imported into model M3 by being appropriatelydeclared in section 72 of model M3.

It should be noted that the `Import` mechanism does not operate toprovide inheritance between models; it is only entities that can bestructured into an inheritance hierarchy.

The core entity types (integers, characters and strings) can beconsidered to form part of a `support` service model which is importedinto every other model enabling the use of core entities in thosemodels. Because these entity types are so widely used, no explicitimport declaration is required, this import being assumed.

A formal description will now be given for service models using aBNF-type language with the following notation:

    ______________________________________                                        ::=            means `is defined by`;                                         *              means there may be one or more instances                                      of the item concerned;                                         .linevert split.                                                                             means OR;                                                      (XYZ.linevert split.)                                                                        means item XYZ OR no item                                      ______________________________________                                        1.   MODEL                                                                         Model       ::=    Modelhead (Imports .linevert split.) (ERgroup)*            Modelhead   ::=    `MODEL` inodel name                                        Imports     ::=    (`IMPORT` model name)*                                     ERgroup     ::=    Entity (Relation)*                                         Modelname   ::=    string                                                2.   ENTITY                                                                        Entity      ::=    CoreEntity .linevert split. ModelEntity                    ModelEntity ::=    `ENTITY` entityName                                                           (`ISA` superEntityName .linevert split.)                   entityName  ::=    string                                                     superEntityName                                                                           ::=    string                                                3.   RELATION                                                                      Relation    ::=    BasicRelation .linevert split. DerivedRelation             BasicRelation                                                                             ::=    `BASIC` relationHead                                                          cardinality(explanation .linevert split.)                  relationHead                                                                              ::=    typeinfo (relationName typeinfo)*                                             (relationName .linevert split.)                            typeinfo    ::=    ` ` ((modelName `.` .linevert split.) entityName                              .linevert split.)                                                             variable `!`                                               cardinality ::=    `O` .linevert split. `M`                                   explanation ::=    `EXPLANATION` (string .linevert split. typeInfo                               option)*                                                   option      ::=    `(` (string .linevert split.) `.linevert split.`                              (string .linevert split.) `)`                         Note: the `explanation` of a relation is used by the system when it           wants                                                                         to output a pseudo-natural language representation of a fact.                 DerivedRelation                                                                            ::=    Head`IF` Body                                             Head         ::=    `DERIVED` relationHead cardinality                                            (explanation .linevert split.)                            Body         ::=    expression                                                expression   ::=    andExpression (`;` andExpression)*                        andExpression                                                                              ::=    expelement (`,` expelement)*                              expelement   ::=    (` expression ` )` .linevert split. `˜`                                 expelement .linevert split.                                                   relationHead                                              ______________________________________                                    

Structuring of Models For a substantial computer system, any particularsystem service, such as print spooling, is best modelled as made up of anumber of internal system services provided to particular systemobjects. The structuring of the service models in such cases willgenerally reflect the physical world structure of the system to agreater or lesser extent. Consider, for example, the modelling of theprinter spooler service illustrated in FIG. 9 in which a user 80(PSUser) working at a machine 81 (PSClientMachine) wishes to print fileon printer 82 (Printer) using a print server 83 (PSServerMachine)coupled to the machine 81 and printer 82 via a network 84 (Network). Thefirst step is to carry out an analysis of which object is requestingwhat service from which other object(s). As can be seen, the user 80needs the "service" S1 called "canPrint file!on prtName!", the purposeof this service being apparent from its name. In order for the user'smachine 81 to provide this service S1 to the user 80, it must have thefollowing conditions satisfied:

1. itself is configured properly internally to provide the service;

2. it can get the service S2 "canFind pSServer!Addr" from somewhere (toidentify a print server 83--in this case, the service S2 is provided bya name server 85);

3. it can get the service S3 "hasRouteTo pSServer!" from somewhere (toenable it to contact the named print server 83 over the network);

4. it can get the service S4 "print file!on prtName!from hostName!" fromsomewhere.

Of the items listed above, only the last "service" is directly relatedto printing the file.

In order that the server machine 83 is able to provide the service 54"print file!on prtName!from hostName!" to the machine 81, it in turnmust have the following conditions satisfied:

1. itself is configured properly internally to provide the service;

2. it can get the service S5 "hasRouteTo printer!" from somewhere;

3. it can get the service S6 "print psFile!" from somewhere.

FIG. 10 shows one possible model structure for the core of the printerspooler service (for convenience, details of the modelling of thenetwork 84, nameserver 85 and printer 82 have not been shown and indeed,models for the services offered by these objects would generally havebeen done in advance of modelling of high level services such as theprinter spooler service).

In the FIG. 10 model structure, the service S1 provided by the user'smachine 81 (`PSClientMachine`) has been rendered as a service model 90(here given the same name for simplicity) that includes an entity type91 (`PSClientService`) corresponding to the service S1 itself. Thisservice entity type 91 will typically have an associated derivedrelation that sets out the conditions needing to be fulfilled for theservice S1 to be available, these conditions corresponding to thosenoted above for the user's machine 81 to provide the service S1. Theservice model 90 also includes an entity type 92 for the user 80(`PSClient`) as generally there will be a condition associated with theservice entity 91 that depends on the user's identity.

The service S4 provided by the print server 83 (`PSServerMachine`) isrendered in the FIG. 10 model structure as a service model 93 thatincludes an entity type 94 (`PSServerService`) corresponding to theservice S4 itself. This service entity type 94 will typically have anassociated derived relation that sets out the conditions needing to befulfilled for the service S4 to be available, these conditionscorresponding to those noted above in relation to the server machine 83.Further entity types 95 (`A ServerEntity`) and 96 (`PSServerMachine`)are also defined for detailing conditions relating to configuration ofthe server machine 83.

Policies it should be noted that the conditions specified in servicemodels for particular service to be available, need not all bedetermined by the technical requirements of the service. Conditions maybe placed on the availability of a service, or more usually on thestatus of a related entity, that are determined by management policywhether local or company wide. Thus, there may be a local site policythat a user's home directory is called by the user's name; such a policycould be readily incorporated into a condition for logging in (i.e. auser can only log in to the computer system if there is a home directorycorresponding to the user's name. Such policy conditions are preferablygrouped in an ER group associated with a Policy entity that is requiredto be `OK` for a given service to be available. Of course, it is notalways clear whether a particular condition is a technical one or apolicy one; for example, a password condition could be viewed as ofeither type.

QUERIES

As previously indicated, associated with each model is a set of queriesfor enabling information to be obtained from the system being managed.Each query is `goodfor` one or more facts, and these facts areidentified with the query to permit selection of the query appropriatefor a desired fact.

A query works by interacting with the system being managed andsyntactically analysing the resultant response into tokens which arethen related to entities and relations. In the present embodiment, theinteraction manager 27 is responsible for running the query whilstfurther semantic analysis of the response is carried out by theknowledge assimilator 32 which is also responsible for updating the factbase.

Three main types of interaction are possible. Firstly, a query may useexisting information-providing services of the system to directlyprovide the required information (though generally packaged with otherinformation and requiring syntactic extraction). Secondly, a query mayexercise a particular capability of the system which although notdirectly supplying the required information, enables the knowledgeassimilator 32 to infer certain facts from the observed results.Thirdly, it is possible to write specific agent programs running onparticular machines of the system being managed, and to provide forthese agents to provide specific answers to particular queries. Whilstsuch agents could provide powerful analysis tools, the need to add tothe system being managed has practical drawbacks and this approach istherefore not preferred.

The general format of a query 100 is illustrated in simplified terms inFIG. 11. The query 100 is, of course, allotted a unique name 101. Next,the action to be performed by the managed system is specified in acommand line 102 that constitutes the `commandspec` of the query. Theremaining part of the query is the `returnSpec` describing what responsecan be expected to result from the action initiated by the command line102 and how this response relates to the entities and relations ofinterest. The `returnSpec` gives the general form of the response(`returnline` 103) in part of a production named RETURN that alsocontains a list 104 (referred to as the `completenessPart`) specifyingthe items for which complete information is available. The `returnline`103 is then syntactically specified (reference 105) to derive a numberof `returnParts` which are then related to entities and relations(reference 106). The facts for which a query is `goodfor` are implicitlyidentified in section 106 of the query and typically an explicit list ofthese facts will be generated when the query is compiled.

Before giving a more formal description of a query, it will be useful tointroduce an example query named `passwd` used to access the Unix`/etc/passwd` file. The form of the example query is given on thefollowing page. This query uses a command line:

cat/etc/passwd

which results in the full file being returned line by line, each linerelating to a different user. The format of a line is illustrated inFIG. 12 in respect of an example user `ajp`. As can be seen, the line ismade up of the following seven elements, separated by a colon,:

name--user's name on the system;

password--user's encrypted password;

uid--user's id number;

gid--user's group id number;

info--miscellaneous items of information;

homeDir--user's home directory

shell--user's shell

The query `passwd` will accordingly be `goodfor` facts relating a userto each of the above items.

In this example, it can be seen that the `completenessSpec` followingRETURN, specifies that the query provides complete information on thefollowing types of fact:

User ₋₋ ! name ₋₋ !

User ₋₋ ! encryptedPassword ₋₋ !

User ₋₋ ! userId ₋₋ !

User ₋₋ ! groupId ₋₋ !

User ₋₋ ! initialHomeDirPath ₋₋ !

User ₋₋ ! initialShellPath ₋₋ !

The syntax of each return line is given after the keyword NEW following`line`; the syntax follows the pattern already described with referenceto FIG. 13. Considering next a `returnpart`, in this case `name`, in theexample the string derived for `name` following syntactic parsing inaccordance with the specification contained in `line`, is allotted to avariable <name> and then applied to the relation " User!name name!" toproduce a fact. In a similar manner facts are produced from the returnparts `password`, `uid`, `gid`, `homeDir` and `Shell`.

    ______________________________________                                        QUERY passwd                                                                  COMMAND ::= `cat /etc/passwd`                                                 RETURN ::= line { User .sub.-- ! name  .sub.-- ! &  User.sub.-- !              encryptedPassword  .sub.-- ! &  User.sub.-- ! userId  .sub.-- !               &  User.sub.-- ! groupId  .sub.-- !                                           &  User.sub.-- ! initialHomeDirPath  .sub.-- !                                &  User.sub.-- ! initialShellPath  .sub.-- !}.                               line ::= (NEW  user! name`:` password `:` uid                                  `;` gid `:` (info .linevert split.) `:` homeDir `:`                           (shell .linevert split.) EOL) +.                                             name ::= string <name>  user! name  name!.                                    password ::= alphaNumString `*/.,`! <password>                                  user! encryptedPassword  password!.                                         uid ::= number <uid>  user! userId  uid!.                                     gid ::= number <gid>  user! groupId  gid!.                                    info ::= alphNumstring `()?.,<>/˜'|@#% &*-                               +={} !`!.                                                                    homeDir ::= alphaNumString `/.-.sub.-- `! <path>  user!                        initialHomeDirPath  path!.                                                   shell ::= alphaNumString `/.-.sub.-- `! <path>  user!                          initialShellPath  path!.                                                     ______________________________________                                    

A more formal description of a query now follows, again with explanatoryreference to the foregoing example query.

A query definition is composed of the following items:

    __________________________________________________________________________     Query::= `QUERY` queryName variableDeclarations                                commandSpec returnSpec delimiterSpec commentSpec                            queryName is a word chosen to identify the query.                             variableDeclarations is used to declare the variables whose values will       passed in                                                                     at run-time for use in the commandSpec. Definition:                            variableDeclarations ::= typeInfo*                                           commandSpec is the specification of the command to be executed on the         (possibly) remote device/machine. Definition:                                  commandSpec ::= `COMMAND` ::= `(string .linevert split. variableName) +      returnSpec defines the syntactic and semantic specification of the return     value                                                                         from executing the command. As can be seen from the earlier example, this     part                                                                          contains a set of BNF-type grammar productions which define the syntax of     the                                                                           return string. The very first productionName must be RETURN. Definition:       returnSpec ::= production +                                                   production ::= productionName `::=` returnLine                                 (`+` .linevert split.) `.`                                                  returnline forms the bulk of each production and is mainly comprised of       the                                                                           names of other produtions (this allowing the hierarchical decomposition       of the                                                                        return string) and reserved words (which specify the type of a terminal       symbol,                                                                       for example an integer). However, embedded within the productions are         also                                                                          some relation heads and completeness infomnation. Definition:                  returnLine ::= (returnEnclosure .linevert split. productionName              .linevert split.                                                                newObj .linevert split. returnPart .linevert split. `ToEOL` .linevert       split. `EOL` .linevert split.                                                   completenessPart )*                                                          returnEnclosure ::= `(` returnLine (`.linevert split.` returnLine)* `)`       newQbj ::- `NEW` typeinfo                                                    NEW causes the creation of a new entity instance every time it is             encountered at                                                                run time. Thus, in the foregoing example whenever the "line" production       is                                                                            encountered while parsing an "/etc/passwd" file, an instance of the           "User" entity                                                                 is created and assigned to the variable "user".                               returnPart relates the tokens returned from parsing to entities and           rations and                                                                   causes facts to be produced which are added to the fact base.                 Definition:                                                                    returnPart ::= fixedReturn .linevert split. valueReturn                       fixedReturn ::= string (newObj .linevert split. relationHead .linevert       split.)                                                                        valueReturn ::= reservedWord ((`<` variableName `>` .linevert split.)          relationHead .linevert split.)                                               reservedWord ::= `number` .linevert split. `hexNumber`                         `string` (` ` string `!` .linevert split.) .linevert split.                   `alphaNumString` (` ` string `!` .linevert split.) .linevert split.           `fileName` .linevert split. `printableString`                               The optional string in square brackets after the "string" and                 "alphaNumString"                                                              reserved words allows the user to add characters to the definition of         these items.                                                                  ToEOL causes the parser to skip everything from the current point to the      end of                                                                        the line.                                                                     EOL tells the parser to expect an end of line at this point.                  "Completeness" as already noted refers to whether, after executing a          query, there                                                                  is total information about an item. For instance, the "/etc/passwd" file      contains                                                                      information about all users on the system. Thus, after executing this         query the                                                                     fact base will contain information about all known users. So, if the          system is                                                                     asked to prove that there was a user of a particular name, and the system     could not                                                                     show that there was a user of this name, then the system can infer that       there is no                                                                   user of that name, since it knows it has information about all users.         Definition:                                                                    completenessPart ::= `{` relationHead (`&` rationHead) * `}`                 delimiterSpec is defined as follows:                                           delimiterSpec is defined as follows:                                         `) stringerspec ::= `DELIMITER ::=` (`+` .linevert split. `                   __________________________________________________________________________

By default the query return string parser uses the space and tabcharacters to delimit tokens. However, there may be cases where thequery writer wishes to change this set. The foregoing example gives aninstance of this; the "info" production needs to use the space characteras a valid character within an information string. The removal of spacefrom the delimiter set causes its automatic addition to thealphaNumString definition.

commentSpec is provided to allow the query writer to specify thenotation used for comments in the query return string. This allows theparser to skip these parts. Definition:

commentSpec ::=`COMMENT` ::=`string `TO` string

ACTIONS

Actions that may need to be performed in order to enable a particulartask to be completed, are defined for each service model in much thesame way as a query but with a simpler basic format:

ACTION--action name

COMMAND--command line

PRE--pre conditions for action

POST--post-conditions (i.e. the effect of the action)

INVALIDATE--variables invalidated by action

The command line will specify a system command (for example, a Unixcommand for Unix Systems) together with identifiers for the items to beacted on (for example, the command line may contain a variable ofdeclared type for specifying the machine on which the action is to becarried out). The preconditions specified in PRE are the conditions thatmust be true before the action can be carried out. The post-conditionsspecified in POST define the effect of the action; it is thesepost-conditions that the inference engine will search when seeking toidentify the action appropriate to effecting a particular task inrelation to the service model for which the action is defined.INVALIDATE identifies the variables invalidated by the action, thisinformation being used to remove from the fact base any facts relying onthe invalidated items.

TASK PROGRAM

As previously explained, the role of each task program 21 (FIG. 3) is toadapt the operation of the inference engine 25 to the task to beperformed. An example diagnosis task program is given below in a pseudonatural language form for ease of understanding.

    ______________________________________                                        DIAGNOSIS TASK                                                                WHILE no solution found DO                                                     Theorem Prover : search for solution;                                         IF more information needed THEN                                                REPEAT find a query UNTIL Verifier: prove pre-conditions END                  perform query;                                                                IF query passes THEN                                                           Knowledge Assimilator: assimilate query pass reasons                         ELSE                                                                           Diagnosis Task: on query failure reasons                                     END                                                                          END                                                                          END                                                                           ______________________________________                                    

The above task program, which can be used in conjunction with anyservice model, searches for a solution to whether the service concerned(as represented by an entity of the corresponding model) is available.This search will proceed through all the conditions specified in therelations associated with the relevant service entity until either it isproved that a required condition is not met or it is proved that allconditions are met and the service is available. In conducting thesearch for a solution, queries may be used to ascertain facts.

Considering the diagnosis task program in more detail, the main theorempower 33 (FIG. 4) is first called upon to search for a solution. Ifduring the course of this search, the theorem power 33 is unable toproceed because a required fact is not present in the fact base 26, thenthe verifier 31 is used to select a query that will elicit the desiredfact from the system. The selected query is then executed (by theinteraction manager 27). If the query is successfully carried out, theresults from the query are assimilated into the fact base by theknowledge assimilator 21 and the program then loops for the theoremprover 33 to continue its search using the newly established facts.However, if the query fails (that is, is not successfully executed),then the diagnosis task is recursively called to establish the reasonfor this failure.

If there is a problem with a service being diagnosed, the abovediagnosis task program will terminate when the theorem prover 33 firstcomes across a fact proving that a requirement for the service to beavailable, has not been met. Because the facts assimilated into the factbase are generally low level facts, the termination of the program atthis stage will normally be acceptable as the termination point willindicate the low-level fact resulting in service non-availability andthis fact will generally be readily translatable into the computersystem fault (including absence of a resource) concerned. However, wherethe fact base stores high-level facts, it is desirable that thediagnosis task program does not terminate at a high-level fact provingservice non-availability, but continues to decompose this fact to derivethe underlying cause as expressed in a low-level fact. This can bereadily achieved by enclosing the above diagnosis task program within a`WHILE` loop of the form:

WHILE failure explanation possible DO

Diagnosis Task

END

In this case, whenever the core diagnosis task terminates on finding afact proving service non-availability, it is asked to find a solutionproving that fact (and ignoring its presence in the fact base). Thisprocess repeats until no further explanation is possible (as indicatedby the absence of any relevant query).

If, in fact, the above additional WHILE loop is not limited to failureexplanation, but is used to explain any solution, then the expandeddiagnosis task can also be used to provide a full check on allconditions (high-level and low-level) required for a particular service.

By tracking the search and using the pseudo natural language factrepresentations contained in the `explanation` element of each relation,it is possible to output a listing of the `reasoning` followed by thetheorem prover 33 in finding a solution.

A further example of a task program is given below in relation to amonitoring task:

MONITORING TASK

WHILE Diagnosis Task: proves monitored goal true DO delay for monitoringinterval

END;

Diagnosis Task: on whole Service

As can be seen, the monitoring task uses the diagnosis task in itsimplementation.

EXAMPLE

Having explained in some detail the concepts of the present inventionand how they may be implemented in one embodiment, a concluding andsomewhat fuller example of a service model will now be given. Theexample chosen is that of the login service provided by a Unixworkstation (Unix is a trademark of AT&T).

Because of the desirability of re-using entities defined in othermodels, as well as the login service model Login, part of a model Unixmodelling the operating system is also given.

The Unix model provides the basic entities relevant when dealing withthe Unix operating system. Here only those entities and relations fromthe Unix model which are useful to understand the parts of the loginmodel are discussed below.

    ______________________________________                                        MODEL Unix                                                                    ENTITY User                                                                   BASIC                                                                           user! initialHomeDirPath  pathname!.                                          user! name  userName!.                                                        user! UserId  integer!.                                                       user! initialShellPath  pathname!.                                            user! groupId  integer!.                                                      user! encryptedPassword  string!.                                           DERIVED                                                                         user! hasReadWriteAccessTo  pathname! IF                                       File file! pathname  pathname!,                                               user! has  `read`! accessTo  file!,                                           user! has  `write`! accessTo  file!.                                         user! has  FileMode mode! accessTo  file! IF                                  ( file! isOwnedBy  user!,                                                      file! ownerMode mode!);                                                      (˜  file! isOwnedBy  user!,                                              file! isInGroupOf  user!,                                                     file! groupMode  mode!);                                                     (˜  file! isOwnedBy  user!,                                             ˜  file! isInGroupOf  user!,                                             file! worldMode  mode!);                                                      user! isSuperUser.                                                         ENTITY File                                                                   BASIC                                                                           file! setGroupId.                                                             file! ownerMode  fileMode!.                                                   file! stickyBit.                                                              file! name  fileName!.                                                        file! size  integer!.                                                         file! worldMode  fileMode!.                                                   file! ownerId  userIdentifier!.                                               file! date  string!.                                                          file! linksCount  integer!.                                                   file! groupMode  fileMode!.                                                   file! groupId  groupIdentifier!.                                              file! setUserId.                                                            DERIVED                                                                         file! isOwnedBy  user! IF                                                      file! ownerId  integer!,                                                      user! userId  integer!.                                                    ______________________________________                                    

Of course, as well as these entities and relations in the Unix model,there are also queries one example of which (Query: `passwd`) has beengiven earlier.

The login service model now follows:

    ______________________________________                                               MODEL LoginService                                                            IMPORT Unix                                                                   ENTITY Login                                                                   login! for  userName! isOk (M:O) IF                                            User user! name  userName!,                                                   user! encryptedPassword  String.sub.-- !,                                     user! userId  UserIdentifier.sub.-- !,                                        user! groupId  GroupIdentifier.sub.-- !                                       user! initialHomeDirIsOk,                                                     user! initialShellIsOk,                                                       login! executableFor  user! isOk,                                             login! auditFilesAreOk.                                              ______________________________________                                    

The foregoing derived relation for the Login entity can be read:

login for a username is ok if

there is a user with that username, and

the user has a password (its value does not matter), and

the user has a user ID (its value does not matter), and

the user has a group ID (its value does not matter), and

the user's home directory is ok, and

the user's shell is ok, and

the login executable files are ok for the user, and

the login audit files are ok.

"name", "encryptedPassword", "UserId" and "groupId" are all basicrelations of the User entity (their real world values are obtained usingthe query `passwd` described above). The other relations are derivedones. Here is the definition of one of them.

login! auditFilesAreOk (M) IF

User root! isSuperUser,

root!hasReadWriteAccessTo Pathname `/etc/utmp`!,

root!hasReadWriteAccessTo Pathname `/etc/btmp`!,

root!hasReadWriteAccessTo Pathname `/etc/wtmp`!,

root!hasReadWriteAccessTo Pathname `/etc/logingroup`!,

login!secureTtyFileIsOk,

login!dialFilesAreOk.

And here is the definition of one of the derived relations referenced bythis:

login!secureTtyFileIsOk(M)IF

˜ File ₋₋ ! pathname Pathname `/etc/securetty`!;

( File ₋₋ ! pathname Pathname `/etc/securetty`!,

User root! isSuperUser,

root! hasReadAccessTo Pathname `/etc/securetty`!).

This relation might translate as:

The login secure tty file is ok if there is not a file/etc/securetty, or(there is a file/etc/securetty, and

there is a super user, and

the super user has read access to/etc/securetty).

Service Verification--The following is the output from the systemmanagement apparatus on proving, by means of the expanded diagnosis taskdescribed above, that login for the user with the name 'sijt` is `OK`.Only the reasons for parts of the models detailed previously areexpanded below.

    ______________________________________                                         login! for (`sijt`!isOk is true                                               because  User25`! name  `sijt`! is true                                        because it is proved by a query                                              because  `User25`! encryptedPassword  `rX2vsS9A3qk1`! is true                 because  `User25`! userId  327! is true                                       because  `User25`! groupId  15! is true                                       because  `User25`!initialShellIsOk is true                                    because  login! executableFor  `User25`!isOk is true                          because  `User25`!initialHomeDirIsOk is true                                  because  login!auditFilesAreOk is true                                         because  `User162`! hasReadwriteAccessTo  `(etc/utmp`! is true                 because  `File397`! endPathname  `/etc/utmp`! is true                         because  `File397`! pathname  `/etc/utmp`! is true                             because  `/etc/utmp`!dirName `/etc`!baseName `utmp`! is true                   because it is proved by a metbod                                             because  Dir392`! pathname  `/etc`! is true                                    because  `/etc`!dirName `/`!baseName `etc`! is true                            because it is proved by a method                                             because  `Dir80`! pathname  `/`! is true                                       because  `/`! equals  `/`! is true                                             because it is proved by a method                                             because  `Dir80`!is Root is true                                               because  `Dir80`! name  `/`! is true                                           because it is proved by a query                                              because  `Dir80`! contains  `Dir80`! is true                                   because it is proved by a query                                            because  `Dir80`! contains  `Dir392`! is true                                  because it is proved by a query                                              because  `Dir392`! name  `etc`! is true                                        because it is proved by a query                                             because  `File397`! name  `utmp`! is true                                      because it is proved by a query                                              because  `Dir392`! contains  `File397`! is true                                because it is proved by a query                                             because  `User162`!has `write`!accessTo File397`! is true                      because  `File397`! ownerMode  `write`! is true                                because it is proved by a query                                              because  `File397`!isOwnedBy  `User162`! is true                               because  `File397`! ownerId  0! is true                                        because it is proved by a query                                              because  `User162`! userId  0! is true                                         because it is proved by a query                                             because  `User162`! has  `read`! accessTo  `File397`! is true                 because  `File397`! ownerMode  `read`! is true                                 because it is proved by a query                                              because  `File397`! isOwnedBy  `User162`! is true                              because  `File397`! ownerId  0! is true                                        because it is proved by a query                                              because  `User162`! userId  0! is true                                         because it is proved by a query                                           because  `User162`!isSuperUser is true                                          because  `User162`! userId  0! is true                                         because it is proved by a query                                          ______________________________________                                    

In the foregoing, reference to a fact being proved by a `method` simplymeans that low-level code has been used to test a particular relationrather than using the fact base and query mechanism. Typically, it isconvenient to carry out tests in this manner for relations between coreentities (number comparison, string matches, etc).

VARIANTS

It will be appreciated that many variants are possible on theabove-described embodiment of the invention. Thus, for example, althougheach task has been described as being subject of a respective taskprogram, it would be possible to provide other task-determined means,besides a program, for controlling the processing of the service models.These other means might include a respective dedicated inference enginefor each task or respective hardware means for controlling a commongeneral purpose processor to perform each task.

At a more detailed level, specific measures may be taken to ensure asfar as reasonably possible, the validity of any facts held in the factbase. For example, each query could be allocated a `lifetime` being thetime for which any facts derived by running the query can be consideredvalid. At the expiration of the query lifetime, all derivative facts(and any further facts based on them) are deleted from the fact base.With such an arrangement, monitoring of system elements can beimplemented by using queries to derive facts on those elements, withthese queries having a lifetime corresponding to the monitoringinterval; upon such a query reaching the end of its life, the facts ofinterest will be removed from the fact base and this can be used by themonitoring task as a trigger for reinitiating the corresponding query.

Furthermore, whilst each service model has associated queries andactions (where appropriate), these queries and actions may be shared bytwo or more models. For example, a query relating to whether a fileexists could well be one used by several different service models and itis clearly more efficient to share the query between models than tospecify the query for each model.

It will be appreciated that any suitable user interface can be providedfor the system management apparatus; in particular, a graphical userinterface may be used in which `drag and drop` actions can serve toimplement tasks in relation to particular instances of different servicemodels.

We claim:
 1. A system management method of carrying out at least onemanagement task in relation to at least one service intended to beprovided by a computer system including cooperating physical and logicalentities, said method comprising the steps of:providing for the or eachsaid at least one service, a respective declarative model specifyingindependently of any particular said task, requirements needing to bemet for the service to be available, these requirements being set out interms of the entities required and the inter-relationships of therequired entities, providing for the or each said at least onemanagement task, respective task control means for controllingperformance of the corresponding task in a manner independent of anyparticular said model and in terms of general inferencing operationsthat can be performed on any said model, and performing a said at leastone management task in relation to a said at least one service by aprocess, activating the process so inferencing operations are performedon the corresponding declarative model under the control of the saidtask control means relevant to that management task.
 2. A systemmanagement method according to claim 1, wherein each said task controlmeans comprises a respective task program for controlling the operationof an inference engine used to perform said at least one managementtask.
 3. A system management method according to claim 1, wherein eachsaid task control means is embodied, at least in part, in a respectiveinference engine used to perform the corresponding task.
 4. A systemmanagement method according to claim 1, wherein said computer systemprovides multiple services in respect of which multiple tasks are to beeffected, said method involving providing a respective said servicemodel for each said multiple service and a respective said task controlmeans for each said multiple task.
 5. A system management methodaccording to claim 1, wherein said computer system is capable ofsupporting a plurality of instantiations of a said service, the saidstep of carrying out a said at least one management task in relation toa said at least one service, involving identifying a said instantiationof the service for which the task is to be carried out and then usingthe appropriate service model to inference information in relation tothe identified service instantiation.
 6. A system management methodaccording to claim 1, wherein at least one said declarative modelcomprises a hierarchical structure of declarative statementsinter-relating entities, statements lower in the hierarchy serving todetail requirements specified by statements higher in said hierarchy. 7.A system management method according to claim 6, wherein said at leastone model includes, in addition to said statements specifyingrequirement statements generally inter-relating said entities and usableto infer whether a particular said requirement has been met.
 8. A systemmanagement method according to claim 6, wherein a plurality of saidservice models are provided each specifying a respective said service,at least two said models being associated such that statements set outin one said model and involving a particular said entity are usable inanother model that also refers to that entity.
 9. A system managementmethod according to claim 1, wherein said requirements comprise both aset of essential technical requirements and a further set of operationalpolicy requirements, these sets being specified separately from eachother.
 10. A system management method according to claim 1, wherein saidstep of carrying out a said at least one management task involvesinteracting with said system to ascertain either directly or throughinferencing from the results of the interaction, whether a saidrequirement relevant to the service concerned is met by the system. 11.A system management method according to claim 1, wherein said methodfurther comprises the step of providing a fact base holding facts on thestatus of the system, said step of carrying out a said at least onemanagement task involving referring to said fact base to ascertainwhether a said requirement relevant to the service concerned can beperformed by the system in the status it has.
 12. A system managementmethod according to claim 1, wherein said method further comprises thestep of providing a fact base holding facts on the status of the system,said step of carrying out a said at least one management task includingascertaining whether a said requirement relevant to the serviceconcerned is met by the system by referring to said fact base for factsrelevant to said requirement, and in the event that insufficient factsabout the status of the system are present in the fact base to ascertainwhether said requirement is met, interacting with the system toascertain either directly or through inferencing from the results ofthis interaction the further needed facts about the status of thesystem.
 13. A system management method according to claim 12, whereinthe results derived from interacting with the system are stored in saidfact base.
 14. A system management method according to claim 1, whereinsaid management task being carried out is a fault diagnosis task.
 15. Asystem management method according to claim 1 wherein said step ofcarrying out a said management task involves changing said system tomeet a said requirement of the service concerned, the changing stepbeing performed by adding or removing an entity or by modifying theinter-relationship between at least two said entities.
 16. A systemmanagement method according to claim 15, wherein said management taskbeing carried out is an installation of said service.
 17. A systemmanagement method according to claim 1 wherein said computer systemcomprises a network of computers.
 18. System management apparatus forcarrying out at least one management task in relation to at least oneservice intended to be provided by a computer system includingcooperating physical and logical entities, said apparatus comprising:adeclarative model specifying independently of any particular said task,the requirements needing to be met for the service to be available,these requirements being set out in terms of the entities required andthe inter-relationships of the required entities, one of saiddeclarative models being provided for the or each said at least oneservice, inference engine means for carrying out inferencing operationsin relation to a said declarative model, task control means, one of saidtask control means being respectively provided for the or each said atleast one management task, each task control means being arranged forcontrolling performance of the corresponding task by said inferenceengine means in a manner independent of any particular said model and interms of general inferencing operations, and means for causing a said atleast one management task to be carried out in relation to a said atleast one service, said means for causing being arranged for causingsaid inference engine means to operate on the corresponding declarativemodel under the control of the said task control means relevant to thatmanagement task.
 19. System management apparatus according to claim 18,said apparatus further comprising fact base means storing facts aboutthe status of said system, and interaction means for interacting withsaid system to ascertain either directly or through inferencing from theresults of the interaction, facts about the status of the system, saidinference engine means being operative in the course of carrying out asaid management task for (a) checking whether a said requirement isbeing met by said system by referring to said fact base means and (b)causing said interaction means to interact with the system to elicitfurther facts in the event that insufficient facts about the status ofthe system are present in the fact base means.